home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1664 < prev    next >
Text File  |  1995-07-26  |  51KB  |  1,292 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       C. Allocchio
  8. Request for Comments: 1664                                     A. Bonito
  9. Category: Experimental                                        GARR-Italy
  10.                                                                  B. Cole
  11.                                                       Cisco Systems Inc.
  12.                                                              S. Giordano
  13.                                      Centro Svizzero Calcolo Scientifico
  14.                                                                R. Hagens
  15.                                              Advanced Network & Services
  16.                                                              August 1994
  17.  
  18.  
  19.                  Using the Internet DNS to Distribute
  20.                   RFC1327 Mail Address Mapping Tables
  21.  
  22. Status of this Memo
  23.  
  24.    This memo defines an Experimental Protocol for the Internet
  25.    community.  This memo does not specify an Internet standard of any
  26.    kind.  Distribution of this memo is unlimited.
  27.  
  28. Abstract
  29.  
  30.    This memo defines how to store in the Internet Domain Name System the
  31.    mapping information needed by e-mail gateways and other tools to map
  32.    RFC822 domain names into X.400 O/R names and vice versa.  Mapping
  33.    information can be managed in a distributed rather than a centralised
  34.    way. Gateways located on Internet hosts can retrieve the mapping
  35.    information querying the DNS instead of having fixed tables which
  36.    need to be centrally updated and distributed.  This memo is a joint
  37.    effort of X400 operation working group (x400ops) and RARE Mail and
  38.    Messaging working group (WG-MSG).
  39.  
  40. 1. Introduction
  41.  
  42.    The connectivity between the Internet SMTP mail and other mail
  43.    services, including the Internet X.400 mail and the commercial X.400
  44.    service providers, is assured by the Mail eXchanger (MX) record
  45.    information distributed via the Internet Domain Name System (DNS). A
  46.    number of documents then specify in details how to convert or encode
  47.    addresses from/to RFC822 style to the other mail system syntax.
  48.    However, only conversion methods provide, via some algorithm or a set
  49.    of mapping rules, a smooth translation, resulting in addresses
  50.    indistinguishable from the native ones in both RFC822 and foreign
  51.    world.
  52.  
  53.    RFC1327 describes a set of mappings which will enable interworking
  54.    between systems operating the CCITT X.400 (1984/88) Recommendations
  55.  
  56.  
  57.  
  58. Allocchio, Bonito, Cole, Giordano & Hagens                      [Page 1]
  59.  
  60. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  61.  
  62.  
  63.    and systems using the RFC822 mail protocol, or protocols derived from
  64.    RFC822. That document addresses conversion of services, addresses,
  65.    message envelopes, and message bodies between the two mail systems.
  66.    This document is concerned with one aspect of RFC1327: the mechanism
  67.    for mapping between X.400 O/R addresses and RFC822 domain names. As
  68.    described in Appendix F of RFC1327, implementation of the mappings
  69.    requires a database which maps between X.400 O/R addresses and domain
  70.    names, and this database is statically defined.
  71.  
  72.    This approach requires many efforts to maintain the correct mapping:
  73.    all the gateways need to get coherent tables to apply the same
  74.    mappings, the conversion tables must be distributed among all the
  75.    operational gateways, and also every update needs to be distributed.
  76.    This static mechanism requires quite a long time to be spent
  77.    modifying and distributing the information, putting heavy constraints
  78.    on the time schedule of every update.  In fact it does not appear
  79.    efficient compared to the Internet Domain Name Service (DNS).  More
  80.    over it does not look feasible to distribute the database to a large
  81.    number of other useful applications, like local address converters,
  82.    e-mail User Agents or any other tool requiring the mapping rules to
  83.    produce correct results.
  84.  
  85.    A first proposal to use the Internet DNS to store, retrieve and
  86.    maintain those mappings was introduced by two of the authors (B. Cole
  87.    and R. Hagens) adopting two new DNS resource record (RR)  types: TO-
  88.    X400 and TO-822. This new proposal adopts a more complete strategy,
  89.    and requires one new RR only. The distribution of the RFC1327 mapping
  90.    rules via DNS is in fact an important service for the whole Internet
  91.    community: it completes the information given by MX resource record
  92.    and it allows to produce clean addresses when messages are exchanged
  93.    among the Internet RFC822 world and the X.400 one (both Internet and
  94.    Public X.400 service providers).
  95.  
  96.    A first experiment in using the DNS without expanding the current set
  97.    of RR and using available ones was in the mean time deployed by some
  98.    of the authors. The existing PTR resource records were used to store
  99.    the mapping rules, and a new DNS tree was created under the ".it" top
  100.    level domain. The result of the experiment was positive, and a few
  101.    test applications ran under this provisional set up. This test was
  102.    also very useful in order to define a possible migration strategy
  103.    during the deployment of the new DNS containing the new RR. The
  104.    Internet DNS nameservers wishing to provide this mapping information
  105.    need in fact to be modified to support the new RR type, and in the
  106.    real Internet, due to the large number of different implementations,
  107.    this takes some time.
  108.  
  109.    The basic idea is to adopt a new DNS RR to store the mapping
  110.    information. The RFC822 to X.400 mapping rules (including the so
  111.  
  112.  
  113.  
  114. Allocchio, Bonito, Cole, Giordano & Hagens                      [Page 2]
  115.  
  116. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  117.  
  118.  
  119.    called 'gate' rules) will be stored in the ordinary DNS tree, while
  120.    the definition of a new branch of the name space defined under each
  121.    national top level domain is envisaged in order to contain the X.400
  122.    to RFC822 mappings. A "two-way" mapping resolution schema is thus
  123.    fully implemented.
  124.  
  125.    The creation of the new domain name space representing the X.400 O/R
  126.    names structure also provides the chance to use the DNS to distribute
  127.    dynamically other X.400 related information, thus solving other
  128.    efficiency problems currently affecting the X.400 MHS service.
  129.  
  130.    In this paper we will adopt the RFC1327 mapping rules syntax, showing
  131.    how it can be stored into the Internet DNS.
  132.  
  133. 1.1 Definitions syntax
  134.  
  135.    The definitions in this document is given in BNF-like syntax, using
  136.    the following conventions:
  137.  
  138.       |   means choice
  139.       \   is used for continuation of a definition over several lines
  140.       []  means optional
  141.       {}  means repeated one or more times
  142.  
  143.    The definitions, however, are detailed only until a certain level,
  144.    and below it self-explaining character text strings will be used.
  145.  
  146. 2. Motivation
  147.  
  148.    Implementations of RFC1327 gateways require that a database store
  149.    address mapping information for X.400 and RFC822. This information
  150.    must be disseminated to all RFC1327 gateways. In the Internet
  151.    community, the DNS has proven to be a practical mean for providing a
  152.    distributed name service. Advantages of using a DNS based system over
  153.    a table based approach for mapping between O/R addresses and domain
  154.    names are:
  155.  
  156.      - It avoids fetching and storing of entire mapping tables by every
  157.        host that wishes to implement RFC1327 gateways and/or tools
  158.  
  159.      - Modifications to the DNS based mapping information can be made
  160.        available in a more timely manner than with a table driven
  161.        approach.
  162.  
  163.      - It allows full authority delegation, in agreement with the
  164.        Internet regionalization process.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Allocchio, Bonito, Cole, Giordano & Hagens                      [Page 3]
  171.  
  172. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  173.  
  174.  
  175.      - Table management is not necessarily required for DNS-based
  176.        RFC1327 gateways.
  177.  
  178.      - One can determine the mappings in use by a remote gateway by
  179.        querying the DNS (remote debugging).
  180.  
  181.    Also many other tools, like address converters and User Agents can
  182.    take advantage of the real-time availability of RFC1327 tables,
  183.    allowing a much easier maintenance of the information.
  184.  
  185. 3. The domain space for X.400 O/R name addresses
  186.  
  187.    Usual domain names (the ones normally used as the global part of an
  188.    RFC822 e-mail address) and their associated information, i.e., host
  189.    IP addresses, mail exchanger names, etc., are stored in the DNS as a
  190.    distributed database under a number of top-level domains. Some top-
  191.    level domains are used for traditional categories or international
  192.    organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand
  193.    any country has its own two letter ISO country code as top-level
  194.    domain (FR, DE, GB, IT, RU, ...), including "US" for USA.  The
  195.    special top-level/second-level couple IN-ADDR.ARPA is used to store
  196.    the IP address to domain name relationship. Our proposal defines in
  197.    the above structure the appropriate way to locate the X.400 O/R name
  198.    space, thus enabling us to store in DNS the RFC1327 mapping data.
  199.  
  200.    The RFC1327 mapping information is composed by three tables: 'table1'
  201.    gives the translation from X.400 to RFC822 while 'table2' and 'gate'
  202.    tables map RFC822 into X.400. Each mapping table is composed by
  203.    mapping rules, and a single mapping rule is composed by a keyword
  204.    (the argument of the mapping function derived from the address to be
  205.    translated) and a translator (the mapping function parameter):
  206.  
  207.                           keyword#translator#
  208.  
  209.    the '#' sign is a delimiter enclosing the translator. An example:
  210.  
  211.                 foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us#
  212.  
  213.    Local mappings are not intended for use outside their restricted
  214.    environment, thus they should not be included in DNS. If local
  215.    mappings are used, they should be stored using static local tables,
  216.    exactly as local static host tables can be used with DNS.
  217.  
  218.    The keyword of a 'table2' and 'gate' table entry is a valid RFC822
  219.    domain; thus the usual domain name space can be used without problems
  220.    to store these entries.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Allocchio, Bonito, Cole, Giordano & Hagens                      [Page 4]
  227.  
  228. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  229.  
  230.  
  231.    On the other hand, the keyword of a 'table1' entry belongs to the
  232.    X.400 O/R name space. The X.400 O/R name space does not usually fit
  233.    into the usual domain name space, although there are a number of
  234.    similarities; a new name structure is thus needed to represent it.
  235.    This new name structure contains the X.400 mail domains.
  236.  
  237.    To ensure the correct functioning of the DNS system, the new X.400
  238.    name structure must be hooked to the existing domain name space in a
  239.    way which respects the existing name hierarchy.
  240.  
  241.    A possible solution was to create another special branch, starting
  242.    from the root of the DNS tree, somehow similar to the in-addr.arpa
  243.    tree. This idea would have required to establish a central authority
  244.    to coordinate at international level the management of each national
  245.    X.400 name tree, including the X.400 public service providers. This
  246.    coordination problem is a heavy burden if approached globally. More
  247.    over the X.400 name structure is very 'country oriented': thus while
  248.    it requires a coordination at national level, it does not have
  249.    concepts like the international root. In fact the X.400 international
  250.    service is based  on a large number of bilateral agreements, and only
  251.    within some communities an international coordination service exists.
  252.  
  253.    The X.400 two letter ISO country codes, however, are the same used
  254.    for the RFC822 country top-level domains and this gives us an
  255.    appropriate hook to insert the new branches. Our proposal is, in
  256.    fact, to create under each national top level ISO country code a new
  257.    branch in the name space. This branch represents exactly the X.400
  258.    O/R name structure as defined in each single country, following the
  259.    ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed
  260.    under each country top-level domain, and hence the national X.400
  261.    name space derives its own structure:
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Allocchio, Bonito, Cole, Giordano & Hagens                      [Page 5]
  283.  
  284. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  285.  
  286.  
  287.                                     . (root)
  288.                                     |
  289.       +-----------------+-----------+--------+-----------------+...
  290.       |                 |                    |                 |
  291.      edu                it                   us                fr
  292.       |                 |                    |                 |
  293.   +---+---+...    +-----+-----+...     +-----+-----+...     +--+---+...
  294.   |       |       |     |     |        |     |     |        |      |
  295.  ...     ...     cnr   X42D  infn      va    ca   X42D     X42D  inria
  296.                         |                    |     |        |
  297.            +------------+------------+...   ...   ...  +----+-------+...
  298.            |            |            |                 |            |
  299.     ADMD-PtPostel  ADMD-garr  ADMD-Master400        ADMD-atlas  ADMD-red
  300.                         |            |                 |            |
  301.              +----------+----+...   ...        +-------+------+... ...
  302.              |               |                 |              |
  303.          PRMD-infn       PRMD-STET        PRMD-Telecom   PRMD-Renault
  304.              |               |                 |              |
  305.             ...             ...               ...            ...
  306.  
  307.  
  308.    The creation of the X.400 new name tree at national level solves the
  309.    problem of the international coordination. Actually the coordination
  310.    problem is just moved at national level, but it thus becomes easier
  311.    to solve. The coordination at national level between the X.400
  312.    communities and the Internet world is already a requirement for the
  313.    creation of the national static RFC1327 mapping tables; the use of
  314.    the Internet DNS gives further motivations for this coordination.
  315.  
  316.    The coordination at national level also fits in the ongoing proposal
  317.    intended to define exactly the RFC1327 Mapping Authorities. The DNS
  318.    in fact allows a step by step authority distribution, up to a final
  319.    complete delegation, which can be easily controlled at national level
  320.    accordingly with national needs and situations. A further advantage
  321.    of the national based solution is to allow each country to set up its
  322.    own X.400 name structure in DNS and to deploy its own authority
  323.    delegation according to its local time scale and requirements, with
  324.    no loss of global service in the mean time. And last, placing the new
  325.    X.400 name tree and coordination process at national level fits into
  326.    the Internet regionalization and internationalisation process, as it
  327.    requires local bodies to take care of local coordination problems.
  328.  
  329.    The DNS name space thus contains completely the information required
  330.    by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a
  331.    simple query to the nearest nameserver provides it. Moreover there is
  332.    no more any need to store, maintain and distribute manually any
  333.    mapping table. The new X.400 name space can also contain further
  334.    information about the X.400 community, as DNS allows for it a
  335.  
  336.  
  337.  
  338. Allocchio, Bonito, Cole, Giordano & Hagens                      [Page 6]
  339.  
  340. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  341.  
  342.  
  343.    complete set of resource records, and thus it allows further
  344.    developments. This set of RRs in the new X.400 name space must be
  345.    considered 'reserved' and thus not used until further specifications.
  346.  
  347.    The construction of the new domain space trees will follow the same
  348.    procedures used when organising at first the already existing DNS
  349.    space: at first the information will be stored in a quite centralised
  350.    way, and distribution of authority will be gradually achieved. A
  351.    separate document will describe the implementation phase and the
  352.    methods to assure a smooth introduction of the new service.
  353.  
  354. 4. The new DNS resource record for RFC1327 mapping rules: PX
  355.  
  356.    The specification of the Internet DNS (RFC1035) provides a number of
  357.    specific resource records (RRs) to contain specific pieces of
  358.    information. In particular they contain the Mail eXchanger (MX) RR
  359.    and the host Address (A) records which are used by the Internet SMTP
  360.    mailers. As we will store the RFC822 to X.400 mapping information in
  361.    the already existing DNS name tree, we need to define a new DNS RR in
  362.    order to avoid any possible clash or misuse of already existing data
  363.    structures. The same new RR will also be used to store the mappings
  364.    from X.400 to RFC822. More over the mapping information, i.e., the
  365.    RFC1327 mapping rules, has a specific format and syntax which require
  366.    an appropriate data structure and processing. A further advantage of
  367.    defining a new RR is the ability to include flexibility for some
  368.    eventual future development.
  369.  
  370.    The definition of the new 'PX' DNS resource record is:
  371.  
  372.       class:        IN   (Internet)
  373.  
  374.       name:         PX   (pointer to X.400/RFC822 mapping information)
  375.  
  376.       value:        26
  377.  
  378.    The PX RDATA format is:
  379.  
  380.           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  381.           |                  PREFERENCE                   |
  382.           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  383.           /                    MAP822                     /
  384.           /                                               /
  385.           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  386.           /                    MAPX400                    /
  387.           /                                               /
  388.           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  389.  
  390.    where:
  391.  
  392.  
  393.  
  394. Allocchio, Bonito, Cole, Giordano & Hagens                      [Page 7]
  395.  
  396. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  397.  
  398.  
  399.    PREFERENCE   A 16 bit integer which specifies the preference given to
  400.                 this RR among others at the same owner.  Lower values
  401.                 are preferred;
  402.  
  403.    MAP822       A <domain-name> element containing <rfc822-domain>, the
  404.                 RFC822 part of the RFC1327 mapping information;
  405.  
  406.    MAPX400      A <domain-name> element containing the value of
  407.                 <x400-in-domain-syntax> derived from the X.400 part of
  408.                 the RFC1327 mapping information (see sect. 4.2);
  409.  
  410.    PX records cause no additional section processing. The PX RR format
  411.    is the usual one:
  412.  
  413.              <name> [<class>] [<TTL>] <type> <RDATA>
  414.  
  415.    When we store in DNS a 'table1' entry, then <name> will be an X.400
  416.    mail domain name in DNS syntax (see sect. 4.2). When we store a
  417.    'table2' or a 'gate' table entry, <name> will be an RFC822 mail
  418.    domain name, including both fully qualified DNS domains and mail only
  419.    domains (MX-only domains). All normal DNS conventions, like default
  420.    values, wildcards, abbreviations and message compression, apply also
  421.    for all the components of the PX RR. In particular <name>, MAP822 and
  422.    MAPX400, as <domain-name> elements, must have the final "." (root)
  423.    when they are fully qualified.
  424.  
  425. 4.1 Additional features of the PX resource record
  426.  
  427.    The definition of the RDATA for the PX resource record, and the fact
  428.    that DNS allows a distinction between an exact value and a wildcard
  429.    match for the <name> parameter, represent an extension of the RFC1327
  430.    specification for mapping rules. In fact, any RFC1327 mapping table
  431.    entry is an implicit wildcard entry, i.e., the rule
  432.  
  433.       net2.it#PRMD$net2.ADMD$p400.C$it#
  434.  
  435.    covers any RFC822 domain ending with 'net2.it', unless more detailed
  436.    rules for some subdomain in 'net2.it' are present. Thus there is no
  437.    possibility to specify explicitly an RFC1327 entry as an exact match
  438.    only rule. In DNS an entry like
  439.  
  440.       *.net2.it.   IN  PX  10   net2.it.  PRMD-net2.ADMD-p400.C-it.
  441.  
  442.    specify the usual wildcard match as for RFC1327 tables. However an
  443.    entry like
  444.  
  445.       ab.net2.it.  IN  PX  10   ab.net2.it.  O-ab.PRMD-net2.ADMDb.C-it.
  446.  
  447.  
  448.  
  449.  
  450. Allocchio, Bonito, Cole, Giordano & Hagens                      [Page 8]
  451.  
  452. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  453.  
  454.  
  455.    is valid only for an exact match of 'ab.net2.it' RFC822 domain.
  456.  
  457.    Note also that in DNS syntax there is no '#' delimiter around MAP822
  458.    and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not
  459.    allow the <blank> (ASCII decimal 32) character within these fields,
  460.    making unneeded the use of an explicit delimiter as required in the
  461.    RFC1327 original syntax.
  462.  
  463.    Another extension to the RFC1327 specifications is the PREFERENCE
  464.    value defined as part of the PX RDATA section. This numeric value has
  465.    exactly the same meaning than the similar one used for the MX RR. It
  466.    is thus possible to specify more than one single mapping for a domain
  467.    (both from RFC822 to X.400 and vice versa), giving as the preference
  468.    order. In RFC1327 static tables, however, you cannot specify more
  469.    than one mapping per each RFC822 domain, and the same restriction
  470.    apply for any X.400 domain mapping to an RFC822 one.
  471.  
  472.    More over, in the X.400 recommendations a note suggests than an
  473.    ADMD=<blank> should be reserved for some special cases. Various
  474.    national functional profile specifications for an X.400 MHS states
  475.    that if an X.400 PRMD is reachable via any of its national ADMDs,
  476.    independently of its actual single or multiple connectivity with
  477.    them, it should use ADMD=<blank> to advertise this fact. Again, if a
  478.    PRMD has no connections to any ADMD it should use ADMD=0 to notify
  479.    its status, etc. However, in most of the current real situations, the
  480.    ADMD service providers do not accept messages coming from their
  481.    subscribers if they have a blank ADMD, forcing them to have their own
  482.    ADMD value. In such a situation there are problems in indicating
  483.    properly the actually working mappings for domains with multiple
  484.    connectivity. The PX RDATA 'PREFERENCE' extension was introduced to
  485.    take in consideration these problems.
  486.  
  487.    However, as these extensions are not available with RFC1327 static
  488.    tables, it is strongly discouraged to use them when interworking with
  489.    any table based gateway or application. The extensions were in fact
  490.    introduced just to add more flexibility, like the PREFERENCE value,
  491.    or they were already implicit in the DNS mechanism, like the wildcard
  492.    specification. They should be used very carefully or just considered
  493.    'reserved for future use'. In particular, for current use, the
  494.    PREFERENCE value in the PX record specification should be fixed to a
  495.    value of 50, and only wildcard specifications should be used when
  496.    specifying <name> values.
  497.  
  498. 4.2 The DNS syntax for an X.400 'domain'
  499.  
  500.    The syntax definition of the RFC1327 mapping rules is defined in
  501.    appendix F of that document. However that syntax is not very human
  502.    oriented and contains a number of characters which have a special
  503.  
  504.  
  505.  
  506. Allocchio, Bonito, Cole, Giordano & Hagens                      [Page 9]
  507.  
  508. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  509.  
  510.  
  511.    meaning in other fields of the Internet DNS. Thus in order to avoid
  512.    any possible problem, especially due to some old DNS implementations
  513.    still being used in the Internet, we define a syntax for the X.400
  514.    part of any RFC1327 mapping rules (and hence for any X.400 O/R name)
  515.    which makes it compatible with a <domain-name> element, i.e.,
  516.  
  517.    <domain-name>    ::= <subdomain> | " "
  518.    <subdomain>      ::= <label> | <label> "." <subdomain>
  519.    <label>          ::= <alphanum>|
  520.                         <alphanum> {<alphanumhyphen>} <alphanum>
  521.    <alphanum>       ::= "0".."9" | "A".."Z" | "a".."z"
  522.    <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
  523.  
  524.    (see RFC1035, section 2.3.1, page 8).  The legal character set for
  525.    <label> does not correspond to the IA5 Printablestring one used in
  526.    RFC1327 to define mapping rules. However a very simple "escape
  527.    mechanism" can be applied in order to bypass the problem. We can in
  528.    fact simply describe the X.400 part of an RFC1327 mapping rule format
  529.    as:
  530.  
  531.      <map-rule>   ::= <map-elem> | <map-elem> { "." <map-elem> }
  532.      <map-elem>   ::= <attr-label> "$" <attr-value>
  533.      <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
  534.      <attr-value> ::= " " | "@" | IA5-Printablestring
  535.  
  536.    As you can notice <domain-name> and <map-rule> look similar, and also
  537.    <label> and <map-elem> look the same. If we define the correct method
  538.    to transform a <map-elem> into a <label> and vice versa the problem
  539.    to write an RFC1327 mapping rule in <domain-name> syntax is solved.
  540.  
  541.    The RFC822 domain part of any RFC1327 mapping rule is of course
  542.    already in <domain-name> syntax, and thus remains unchanged.
  543.  
  544.    In particular, in a 'table1' mapping rule the 'keyword' value must be
  545.    converted into <x400-in-domain-syntax> (X.400 mail DNS mail domain),
  546.    while the 'translator' value is already a valid RFC822 domain.  Vice
  547.    versa in a 'table2' or 'gate' mapping rule, the 'translator' must be
  548.    converted into <x400-in-domain-syntax>, while the 'keyword' is
  549.    already a valid RFC822 domain.
  550.  
  551. 4.2.1 IA5-Printablestring to <alphanumhyphen> mappings
  552.  
  553.    The problem of unmatching IA5-Printablestring and <label> character
  554.    set definition is solved by a simple character mapping rule: whenever
  555.    an IA5 character does not belong to <alphanumhyphen>, then it is
  556.    mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A
  557.    small set of special rules is also defined for the most frequent
  558.    cases. Moreover some frequent characters combinations used in RFC1327
  559.  
  560.  
  561.  
  562. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 10]
  563.  
  564. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  565.  
  566.  
  567.    rules are also mapped as special cases.
  568.  
  569.    Let's then define the following simple rules:
  570.  
  571.     RFC1327 rule          DNS store translation    conditions
  572.     -----------------------------------------------------------------
  573.     <attr-label>$@        <attr-label>             missing attribute
  574.     <attr-label>$<blank>  <attr-label>"b"          blank attribute
  575.     <attr-label>$xxx      <attr-label>-xxx         elsewhere
  576.  
  577.    Non <alphanumhyphen> characters in <attr-value>:
  578.  
  579.     RFC1327 rule          DNS store translation    conditions
  580.     -----------------------------------------------------------------
  581.     -                     -h-                      hyphen
  582.     \.                    -d-                      quoted dot
  583.     <blank>               -b-                      blank
  584.     <non A/N character>   -<3digit-decimal>-       elsewhere
  585.  
  586.    If the DNS store translation of <attr-value> happens to end with an
  587.    hyphen, then this last hyphen is omitted.
  588.  
  589.    Let's now have some examples:
  590.  
  591.     RFC1327 rule          DNS store translation    conditions
  592.     -----------------------------------------------------------------
  593.     PRMD$@                PRMD                     missing attribute
  594.     ADMD$<blank>          ADMDb                    blank attribute
  595.     ADMD$400-net          ADMD-400-h-net           hyphen mapping
  596.     PRMD$UK\.BD           PRMD-UK-d-BD             quoted dot mapping
  597.     O$ACME Inc\.          O-ACME-b-Inc-d           blank & final hyphen
  598.     PRMD$main-400-a       PRMD-main-h-400-h-a      hyphen mapping
  599.     O$-123-b              O--h-123-h-b             hyphen mapping
  600.     OU$123-x              OU-123-h-x               hyphen mapping
  601.     PRMD$Adis+co          PRMD-Adis-043-co         3digit mapping
  602.  
  603.    Thus, an X.400 part from an RFC1327 mapping rule like
  604.  
  605.      OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc
  606.  
  607.    translates to
  608.  
  609.      OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc
  610.  
  611.  Another example:
  612.  
  613.      OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB
  614.  
  615.  
  616.  
  617.  
  618. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 11]
  619.  
  620. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  621.  
  622.  
  623.    translates to
  624.  
  625.      OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB
  626.  
  627. 4.2.2 Flow chart
  628.  
  629.    In order to achieve the proper DNS store translations of the X.400
  630.    part of an RFC1327 mapping rules or any other X.400 O/R name, some
  631.    software tools will be used. It is in fact evident that the above
  632.    rules for converting mapping table from RFC1327 to DNS format (and
  633.    vice versa) are not user friendly enough to think of a human made
  634.    conversion.
  635.  
  636.    To help in designing such tools, we describe hereunder a small flow
  637.    chart. The fundamental rule to be applied during translation is,
  638.    however, the following:
  639.  
  640.       "A string must be parsed from left to right, moving appropriately
  641.       the pointer in order not to consider again the already translated
  642.       left section of the string in subsequent analysis."
  643.  
  644.    Flow chart 1 - Translation from RFC1327 to DNS format:
  645.  
  646.  
  647.                  parse  single attribute
  648.               (enclosed in "." separators)
  649.                            |
  650.             (yes)  ---  <label>$@ ?  ---  (no)
  651.               |                             |
  652.         map to <label>        (no)  <label>$<blank> ?  (yes)
  653.               |                 |                        |
  654.               |           map to <label>-        map to <label>"b"
  655.               |                 |                        |
  656.               |           map "\." to -d-                |
  657.               |                 |                        |
  658.               |           map "-" to -h-                 |
  659.               |                 |                        |
  660.               |    map non A/N char to -<3digit>-        |
  661.   restart     |                 |                        |
  662.      ^        |      remove (if any) last "-"            |
  663.      |        |                 |                        |
  664.      |        \------->     add a  "."    <--------------/
  665.      |                          |
  666.      \----------  take  next  attribute  (if  any)
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 12]
  675.  
  676. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  677.  
  678.  
  679.    Flow chart 2 - Translation from DNS to RFC1327 format:
  680.  
  681.  
  682.                 parse single attribute
  683.             (enclosed in "." separators)
  684.                           |
  685.             (yes) ---- <label> ? ---- (no)
  686.               |                          |
  687.       map to <label>$@        (no) <label>"b" ? (yes)
  688.               |                 |                 |
  689.               |           map to <label>$    map to <label>$<blank>
  690.               |                 |                 |
  691.               |           map -d- to "\."         |
  692.               |                 |                 |
  693.               |           map -h- to "-"          |
  694.               |                 |                 |
  695.               |           map -b- to " "          |
  696.   restart     |                 |                 |
  697.      ^        |   map -<3digit>- to non A/N char  |
  698.      |        |                 |                 |
  699.      |        \-------->   add a "."   <----------/
  700.      |                         |
  701.      \------------- take next attribute (if any)
  702.  
  703.  
  704.    Note that the above flow charts deal with the translation of the
  705.    attributes syntax, only.
  706.  
  707. 4.2.3 The Country Code convention in the <name> value.
  708.  
  709.    The RFC822 domain space and the X.400 O/R address space, as said in
  710.    section 3, have one specific common feature: the X.400 ISO country
  711.    codes are the same as the RFC822 ISO top level domains for countries.
  712.    In the previous sections we have also defined a method to write in
  713.    <domain-name> syntax any X.400 domain, while in section 3 we
  714.    described the new name space starting at each country top level
  715.    domain under the X42D.cc (where 'cc' is then two letter ISO country
  716.    code).
  717.  
  718.    The <name> value for a 'table1' entry in DNS should thus be derived
  719.    from the X.400 domain value, translated to <domain-name> syntax,
  720.    adding the 'X42D.cc.' post-fix to it, i.e.,
  721.  
  722.       ADMD$acme.C$fr
  723.  
  724.    produces in <domain-name> syntax the key:
  725.  
  726.       ADMD-acme.C-fr
  727.  
  728.  
  729.  
  730. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 13]
  731.  
  732. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  733.  
  734.  
  735.    which is post-fixed by 'X42D.fr.' resulting in:
  736.  
  737.       ADMD-acme.C-fr.X42D.fr.
  738.  
  739.    However, due to the identical encoding for X.400 country codes and
  740.    RFC822 country top level domains, the string 'C-fr.X42D.fr.' is
  741.    clearly redundant.
  742.  
  743.    We thus define the 'Country Code convention' for the <name> key,
  744.    i.e.,
  745.  
  746.       "The C-cc section of an X.400 domain in <domain-name> syntax must
  747.       be omitted when creating a <name> key, as it is identical to the
  748.       top level country code used to identify the DNS zone where the
  749.       information is stored".
  750.  
  751.    Thus we obtain the following <name> key examples:
  752.  
  753.    X.400 domain                       DNS <name> key
  754.    --------------------------------------------------------------------
  755.    ADMD$acme.C$fr                     ADMD-acme.X42D.fr.
  756.    PRMD$ux\.av.ADMD$ .C$gb            PRMD-ux-d-av.ADMDb.X42D.gb.
  757.    PRMD$ppb.ADMD$Dat 400.C$de         PRMD-ppb.ADMD-Dat-b-400.X42D.de.
  758.  
  759. 4.3 Creating the appropriate DNS files
  760.  
  761.    Using RFC1327's assumption of an asymmetric mapping between X.400 and
  762.    RFC822 addresses, two separate relations are required to store the
  763.    mapping database: RFC1327 'table1' and RFC1327 'table2'; thus also in
  764.    DNS we will maintain the two different sections, even if they will
  765.    both use the PX resource record. More over RFC1327 also specify a
  766.    third table: RFC1327 'gate' Table. This additional table, however,
  767.    has the same syntax rules than RFC1327 'table2' and thus the same
  768.    translation procedure as 'table2' will be applied; some details about
  769.    the RFC1327 'gate' table are discussed in section 4.4.
  770.  
  771.    Let's now check how to create, from an RFC1327 mapping rule entry,
  772.    the appropriate DNS entry in a DNS data file. We can again define an
  773.    RFC1327 mapping rule entry as defined in appendix F of that document
  774.    as:
  775.  
  776.      <x400-domain>#<rfc822-domain>#  (case A: 'table1' entry)
  777.  
  778.    and
  779.  
  780.      <rfc822-domain>#<x400-domain>#  (case B: 'table2' and 'gate' entry)
  781.  
  782.    The two cases must be considered separately. Let's consider case A.
  783.  
  784.  
  785.  
  786. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 14]
  787.  
  788. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  789.  
  790.  
  791.     - take <x400-domain> and translate it into <domain-name> syntax,
  792.       obtaining <x400-in-domain-syntax>;
  793.     - create the <name> key from <x400-in-domain-syntax> i.e., apply
  794.       the Country Code convention described in sect. 4.2.3;
  795.     - construct the DNS PX record as:
  796.  
  797.       *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
  798.  
  799.    Please note that within PX RDATA the <rfc822-domain> precedes the
  800.    <x400-in-domain-syntax> also for a 'table1' entry.
  801.  
  802.    an example: from the rule
  803.  
  804.      PRMD$ab.ADMD$ac.C$fr#ab.fr#
  805.  
  806.    we obtain
  807.  
  808.      *.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
  809.  
  810.    Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are
  811.    fully qualified <domain-name> elements, thus ending with a ".".
  812.  
  813.    Let's now consider case B.
  814.  
  815.     - take <rfc822-domain> as <name> key;
  816.     - translate <x400-domain> into <x400-in-domain-syntax>;
  817.     - construct the DNS PX record as:
  818.  
  819.      *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
  820.  
  821.    an example: from the rule
  822.  
  823.      ab.fr#PRMD$ab.ADMD$ac.C$fr#
  824.  
  825.    we obtain
  826.  
  827.      *.ab.fr.  IN  PX  50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
  828.  
  829.    Again note the fully qualified <domain-name> elements.
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 15]
  843.  
  844. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  845.  
  846.  
  847.    A file containing the RFC1327 mapping rules and RFC1327 'gate' table
  848.    written in DNS format will look like the following fictious example:
  849.  
  850.      !
  851.      ! RFC1327 table 1: X.400 --> RFC822
  852.      !
  853.      *.ADMD-acme.X42D.it.               IN  PX  50  it. ADMD-acme.C-it.
  854.      *.PRMD-accred.ADMD-tx400.X42D.it.  IN  PX  50   \
  855.                                 accred.it. PRMD-accred.ADMD-tx400.C-it.
  856.      *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it.  IN  PX  50   \
  857.                        cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it.
  858.      !
  859.      ! RFC1327 table 2: RFC822 --> X.400
  860.      !
  861.      *.nrc.it.    IN  PX  50   nrc.it. PRMD-nrc.ADMD-acme.C-it.
  862.      *.ninp.it.   IN  PX  50   ninp.it. O.PRMD-ninp.ADMD-acme.C-it.
  863.      *.bd.it.     IN  PX  50   bd.it. PRMD-uk-d-bd.ADMDb.C-it.
  864.      !
  865.      ! RFC1327 Gate Table
  866.      !
  867.      my.it.  IN PX 50  my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G.
  868.      co.it.  IN PX 50  co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G.
  869.  
  870.    (here the "\" indicates continuation on the same line, as wrapping is
  871.    done only due to typographical reasons).
  872.  
  873.    Note the special suffix ".G." on the right side of the 'gate' Table
  874.    section whose aim is described in section 4.4. The corresponding
  875.    RFC1327 tables are:
  876.  
  877.  
  878.      #
  879.      # RFC1327 table 1: X.400 --> RFC822
  880.      #
  881.      ADMD$acme.C$it#it#
  882.      PRMD$accred.ADMD$tx400.C$it#accred.it#
  883.      O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it#
  884.      #
  885.      # RFC1327 table 2: RFC822 --> X.400
  886.      #
  887.      nrc.it#PRMD$nrc.ADMD$acme.C$it#
  888.      ninp.it#O.PRMD$ninp.ADMD$acme.C$it#
  889.      bd.it#PRMD$uk\.bd.ADMD$ .C$it#
  890.      #
  891.      # RFC1327 Gate Table
  892.      #
  893.      my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
  894.      co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#
  895.  
  896.  
  897.  
  898. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 16]
  899.  
  900. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  901.  
  902.  
  903. 4.4 Storing the RFC1327 Gate table
  904.  
  905.    Section 4.3.4 of RFC1327 also specify how an address should be
  906.    converted between RFC822 and X.400 in case a complete mapping is
  907.    impossible. To allow the use of DDAs for non mappable domains, the
  908.    RFC1327 'gate' table is thus introduced. DNS must store and
  909.    distribute also these data.
  910.  
  911.    One of the major features of the DNS is the ability to distribute the
  912.    authority: a certain site runs the "primary" nameserver for one
  913.    determined sub-tree and thus it is also the only place allowed to
  914.    update information regarding that sub-tree. This fact allows, in our
  915.    case, a further additional feature to the table based approach. In
  916.    fact we can avoid one possible ambiguity about the use of the 'gate'
  917.    table (and thus of DDAs encoding).
  918.  
  919.    The authority maintaining a DNS entry in the usual RFC822 domain
  920.    space is the only one allowed to decide if its domain should be
  921.    mapped using Standard Attributes (SA) syntax or Domain Defined
  922.    Attributes (DDA) one. If the authority decides that its RFC822 domain
  923.    should be mapped using SA, then the PX RDATA will be a 'table2'
  924.    entry, otherwise it will be a 'gate' table entry. Thus for an RFC822
  925.    domain we cannot have any more two possible entries, one from 'table2
  926.    and another one from 'gate' table, and the action for a gateway
  927.    results clearly stated.
  928.  
  929.    The RFC1327 'gate' table syntax is actually identical to RFC1327
  930.    'table2'. Thus the same syntax translation rules from RFC1327 to DNS
  931.    format can be applied. However a gateway or any other application
  932.    must know if the answer it got from DNS contains some 'table2' or
  933.    some 'gate' table information. This is easily obtained flagging with
  934.    an additional ".G." post-fix the PX RDATA value when it contains a
  935.    'gate' table entry. The example in section 4.3 shows clearly the
  936.    result. As any X.400 O/R domain must end with a country code ("C-xx"
  937.    in our DNS syntax) the additional ".G." creates no conflicts or
  938.    ambiguities at all. This postfix must obviously be removed before
  939.    using the RFC1327 'gate' table data.
  940.  
  941. 5. Finding RFC1327 mapping information from DNS
  942.  
  943.    The RFC1327 mapping information is stored in DNS both in the normal
  944.    RFC822 domain name space, and in the newly defined X.400 name space.
  945.    The information, stored in PX resource records, does not represent a
  946.    full RFC822 or X.400 O/R address: it is a template which specifies
  947.    the fields of the domain that are used by the mapping algorithm.
  948.  
  949.    When mapping information is stored in the DNS, queries to the DNS are
  950.    issued whenever an iterative search through the mapping table would
  951.  
  952.  
  953.  
  954. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 17]
  955.  
  956. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  957.  
  958.  
  959.    be performed (RFC1327: section 4.3.4, State I; section 4.3.5, mapping
  960.    B). Due to the DNS search mechanism, DNS by itself returns the
  961.    longest possible match in the stored mapping rule with a single
  962.    query, thus no iteration and/or multiple queries are needed. As
  963.    specified in RFC1327, a search of the mapping table will result in
  964.    either success (mapping found) or failure (query failed, mapping not
  965.    found).
  966.  
  967.    When a DNS query is issued, a third possible result is timeout. If
  968.    the result is timeout, the gateway operation is delayed and then
  969.    retried at a later time. A result of success or failure is processed
  970.    according to the algorithms specified in RFC1327. If a DNS error code
  971.    is returned, an error message should be logged and the gateway
  972.    operation is delayed as for timeout. These pathological situations,
  973.    however, should be avoided with a careful duplication and chaching
  974.    mechanism which DNS itself provides.
  975.  
  976.    Searching the nameserver which can authoritatively solve the query is
  977.    automatically performed by the DNS distributed name service.
  978.  
  979. 5.1 A DNS query example
  980.  
  981.    An RFC1327 mail-gateway located in the Internet, when translating
  982.    addresses from RFC822 to X.400, can get information about the RFC1327
  983.    mapping rule asking the DNS. As an example, when translating the
  984.    address SUN.CCE.NRC.IT, the gateway will just query DNS for the
  985.    associated PX resource record. The DNS should contain a PX record
  986.    like this:
  987.  
  988.    *.cce.nrc.it.  IN PX 50   cce.nrc.it.  O-cce.PRMD-nrc.ADMD-acme.C-it.
  989.  
  990.    The first query will return immediately the appropriate mapping rule
  991.    in DNS store format.
  992.  
  993.    There is no ".G." at the end of the obtained PX RDATA value, thus
  994.    applying the syntax translation specified in paragraph 4.2 the
  995.    RFC1327 Table 2 mapping rule will be obtained.
  996.  
  997.    Let's now take another example where a 'gate' table rule is returned.
  998.    If we are looking for an RFC822 domain ending with top level domain
  999.    "MW", and the DNS contains a PX record like this,
  1000.  
  1001.       *.mw.   IN  PX  50  mw.  O-cce.PRMD-nrc.ADMD-acme.C-it.G.
  1002.  
  1003.    DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a
  1004.    'gate' table entry in DNS store format. Dropping the final ".G." and
  1005.    applying the syntax translation specified in paragraph 4.2 the
  1006.    original rule will be available. More over, the ".G." flag also tells
  1007.  
  1008.  
  1009.  
  1010. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 18]
  1011.  
  1012. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  1013.  
  1014.  
  1015.    the gateway to use DDA encoding for the inquired RFC822 domain.
  1016.  
  1017.    On the other hand, translating from X.400 to RFC822 the address
  1018.  
  1019.       C=de; ADMD=pkz; PRMD=nfc; O=top;
  1020.  
  1021.    the mail gateway should convert the syntax according to paragraph
  1022.    4.2, apply the 'Country code convention' described in 4.2.3 to derive
  1023.    the appropriate DNS translation of the X.400 O/R name and then query
  1024.    DNS for the corresponding PX resource record. The obtained record for
  1025.    which the PX record must be queried is thus:
  1026.  
  1027.       O-top.PRMD-nfc.ADMD-pkz.X42D.de.
  1028.  
  1029.    The DNS could contain:
  1030.  
  1031.       *.ADMD-pkz.X42D.de.  IN  PX  50  pkz.de.  ADMD-pkz.C-de.
  1032.  
  1033.    Assuming that there are not more specific records in DNS, the
  1034.    wildcard mechanism will return the RFC1327 'table1' rule in encoded
  1035.    format.
  1036.  
  1037. 6. Administration of mapping information
  1038.  
  1039.    The DNS, using the PX RR, will be able to distribute the mapping
  1040.    information to all RFC1327 gateways located on the Internet. However,
  1041.    not all RFC1327 gateways will be able to use the Internet DNS. It is
  1042.    expected that some gateways in a particular management domain will
  1043.    conform to one of the following models:
  1044.  
  1045.       (a) Table-based, (b) DNS-based, (c) X.500-based
  1046.  
  1047.    Table-based management domains will continue to submit and retrieve
  1048.    their mapping tables from the International Mapping Table coordinator
  1049.    manually or via some automated procedures. Their mapping information
  1050.    should be made available in DNS by the appropriate DNS authority
  1051.    using the same mechanism already in place for MX records: if a branch
  1052.    has not yet in place its own DNS server, some higher authority in the
  1053.    DNS tree will provide the service for it. A transition procedure
  1054.    similar to the one used to migrate from the 'hosts.txt' tables to DNS
  1055.    can be applied also to the deployment phase of this proposal. An
  1056.    informational document describing the implementation phase and the
  1057.    detailed coordination procedures is expected. The deployment phase
  1058.    must also follow the directives produced by the current work on
  1059.    RFC1327 mapping authorities, in order to insure consistency in the
  1060.    mapping information itself.
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 19]
  1067.  
  1068. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  1069.  
  1070.  
  1071.    Another distributed directory service which can distribute the
  1072.    RFC1327 mapping information is X.500. The coordination, alignment and
  1073.    uniqueness of mapping information between DNS and X.500 is an
  1074.    essential fact if it happens to have both systems in place. The ideal
  1075.    solution is a dynamic alignment mechanism which transparently makes
  1076.    the DNS mapping information available in X.500 and vice versa. Some
  1077.    work in this specific field is already being done [see Costa] which
  1078.    can result in a global transparent directory service, where the
  1079.    information is stored in DNS or in X.500, but is visible completely
  1080.    by any of the two systems.
  1081.  
  1082. 7. Conclusion
  1083.  
  1084.    The introduction of the new PX resource record and the definition of
  1085.    the X.400 O/R name space in the DNS structure provide a good
  1086.    repository for mapping information. The mapping information is stored
  1087.    in the DNS tree structure so that it can be easily obtained using the
  1088.    DNS distributed name service. At the same time the definition of the
  1089.    appropriate DNS space for X.400 O/R names provide a repository where
  1090.    to store and distribute some other X.400 MHS information. The use of
  1091.    the DNS has many known advantages in storing, managing and updating
  1092.    the information. A successful number of tests have been performed
  1093.    under the provisional top level domain "X400.IT", and their results
  1094.    confirmed the advantages of the method.
  1095.  
  1096.    Software to query the DNS and then to convert between the textual
  1097.    representation of DNS resource records and the address format defined
  1098.    in RFC1327 needs to be developed. This software must also allow a
  1099.    smooth implementation and deployment period, eventually taking care
  1100.    of the transition phase. A further informational document describing
  1101.    operational and implementation of the service is expected.
  1102.  
  1103. 8. Acknowledgements
  1104.  
  1105.    We wish to thanks all those who contributed to the discussion and
  1106.    revision of this document: many of their ideas and suggestions
  1107.    constitute essential parts of this work. In particular thanks to Jon
  1108.    Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops, RARE
  1109.    wg-msg and IETF namedroppers groups. A special mention to Christian
  1110.    Huitema for his fundamental contribution to this work.
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 20]
  1123.  
  1124. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  1125.  
  1126.  
  1127. 9. References
  1128.  
  1129.    [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling
  1130.        Systems: System Model - Service Elements", October 1988.
  1131.  
  1132.    [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC
  1133.        822", RFC 1327, March 1992.
  1134.  
  1135.    [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
  1136.        STD 13, RFC 1034, USC/Information Sciences Institute, November
  1137.        1987.
  1138.  
  1139.    [RFC 1035] Mockapetris, P., "Domain names - Implementation and
  1140.        Specification", STD 13, RFC 1035, USC/Information Sciences
  1141.        Institute, November 1987.
  1142.  
  1143.    [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC
  1144.        1033, SRI International, November 1987.
  1145.  
  1146.    [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and
  1147.        Managing DNS Information in the X.500 Directory", Proceeding of
  1148.        the 4th Joint European Networking Conference, Trondheim, NO, May
  1149.        1993.
  1150.  
  1151.    [Houttin] Houttin, J., Hansen, K., and S. Aumont, "Address Mapping
  1152.        Functions and Authorities", Internet-DRAFT, May 1993.
  1153.  
  1154. 10. Security Considerations
  1155.  
  1156.    Security issues are not discussed in this memo.
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 21]
  1179.  
  1180. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  1181.  
  1182.  
  1183. 11. Authors' Addresses
  1184.  
  1185.    Claudio Allocchio
  1186.    Sincrotrone Trieste
  1187.    Padriciano 99
  1188.    I 34012 Trieste
  1189.    Italy
  1190.  
  1191.    RFC822: Claudio.Allocchio@elettra.trieste.it
  1192.    X.400:  C=it;A=garr;P=Trieste;O=Elettra;
  1193.    S=Allocchio;G=Claudio;
  1194.    Phone:  +39 40 3758523
  1195.    Fax:    +39 40 226338
  1196.  
  1197.  
  1198.    Antonio Blasco Bonito
  1199.    CNUCE - CNR
  1200.    Reparto infr. reti
  1201.    Viale S. Maria 36
  1202.    I 56126 Pisa
  1203.    Italy
  1204.  
  1205.    RFC822: bonito@cnuce.cnr.it
  1206.    X.400:  C=it;A=garr;P=cnr;O=cnuce;S=bonito;
  1207.    Phone:  +39 50 593246
  1208.    Fax:    +39 50 589354
  1209.  
  1210.  
  1211.    Bruce Cole
  1212.    Cisco Systems Inc.
  1213.    P.O. Box 3075
  1214.    1525 O'Brien Drive
  1215.    Menlo Park, CA 94026
  1216.    U.S.A.
  1217.  
  1218.    RFC822: bcole@cisco.com
  1219.    X.400:  C=us;A= ;P=Internet;
  1220.    DD.rfc-822=bcole(a)cisco.com;
  1221.    Phone:  +1 415 6888245
  1222.    Fax:    +1 415 6884575
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 22]
  1235.  
  1236. RFC 1664          Internet DNS for Mail Mapping Tables       August 1994
  1237.  
  1238.  
  1239.    Silvia Giordano
  1240.    Centro Svizzero di
  1241.    Calcolo Scientifico
  1242.    Via Cantonale
  1243.    CH 6928 Manno
  1244.    Switzerland
  1245.  
  1246.    RFC822: giordano@cscs.ch
  1247.    X.400:  C=ch;A=arcom;P=switch;O=cscs;
  1248.    S=giordano;
  1249.    Phone:  +41 91 508213
  1250.    Fax:    +41 91 506711
  1251.  
  1252.  
  1253.    Robert Hagens
  1254.    Advanced Network and Services
  1255.    1875 Campus Commons Drive
  1256.    Reston, VA 22091
  1257.    U.S.A.
  1258.  
  1259.    RFC822: hagens@ans.net
  1260.    X.400:  C=us;A= ;P=Internet;
  1261.    DD.rfc-822=hagens(a)ans.net;
  1262.    Phone:  +1 703 7587700
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 23]
  1291.  
  1292.